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Abstract 


This document provides procedures for registering extensible elements 
of the Lightweight Directory Access Protocol (LDAP). The document 
also provides guidelines to the Internet Assigned Numbers Authority 
(IANA) describing conditions under which new values can be assigned. 


1. Introduction 


The Lightweight Directory Access Protocol [RFC4510] (LDAP) is an 
extensible protocol. LDAP supports: 


- the addition of new operations, 
- the extension of existing operations, and 
- the extensible schema. 


This document details procedures for registering values used to 
unambiguously identify extensible elements of the protocol, including 
the following: 


- LDAP message types 

— LDAP extended operations and controls 
- LDAP result codes 

- LDAP authentication methods 

- LDAP attribute description options 

- Object Identifier descriptors 
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These registries are maintained by the Internet Assigned Numbers 
Authority (IANA). 


In addition, this document provides guidelines to IANA describing the 
conditions under which new values can be assigned. 


This document replaces RFC 3383. 
2. Terminology and Conventions 
This section details terms and conventions used in this document. 
2.1. Policy Terminology 
The terms "IESG Approval", "Standards Action", "IETF Consensus", 
"Specification Required", "First Come First Served", "Expert Review", 


and "Private Use" are used as defined in BCP 26 [RFC2434]. 


The term "registration owner" (or "owner") refers to the party 
authorized to change a value’s registration. 


2.2. Requirement Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14 [RFC2119]. In 
this case, "the specification", as used by BCP 14, refers to the 
processing of protocols being submitted to the IETF standards 
process. 


2.3. Common ABNF Productions 


A number of syntaxes in this document are described using ABNF 


[RFC4234]. These syntaxes rely on the following common productions: 
ALPHA = %x41-5A / %x61-7A ; "A"-"z" / "a"-"z" 
LDIGIT = %x31-39 ; "1"-"o" 
DIGIT = %x30 / LDIGIT ; "o"="9" 


HYPHEN = %x2D po OEM, 
DOT = %Sx2E ie ae 
number = DIGIT / ( LDIGIT 1*DIGIT ) 
keychar = ALPHA / DIGIT / HYPHEN 
leadkeychar = ALPHA 

keystring = leadkeychar *keychar 
keyword = keystring 


Keywords are case insensitive. 
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3. IANA Considerations for LDAP 


This section details each kind of protocol value that can be 
registered and provides IANA guidelines on how to assign new values. 


TANA may reject obviously bogus registrations. 
LDAP values specified in RFCs MUST be registered. Other LDAP values, 
except those in private-use name spaces, SHOULD be registered. RFCs 
SHOULD NOT reference, use, or otherwise recognize unregistered LDAP 
values. 

3.1. Object Identifiers 
Numerous LDAP schema and protocol elements are identified by Object 
Identifiers (OIDs) [X.680]. Specifications that assign OIDs to 
elements SHOULD state who delegated the OIDs for their use. 


For IETF-developed elements, specifications SHOULD use OIDs under 


"Internet Directory Numbers" (1.3.6.1.1.x). For elements developed 
by others, any properly delegated OID can be used, including those 
under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private 


Enterprise Numbers" (1.3.6.1.4.1.x). 


Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert 
Review with Specification Required. Only one OID per specification 
will be assigned. The specification MAY then assign any number of 
OIDs within this arc without further coordination with IANA. 


Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by 
IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Practices for IANA 
assignment of Internet Private Enterprise Numbers are detailed in RFC 
2578 [RFC2578]. 


To avoid interoperability problems between early implementations of a 
"work in progress" and implementations of the published specification 
(e.g., the RFC), experimental OIDs SHOULD be used in "works in 
progress" and early implementations. OIDs under the Internet 
Experimental OID arc (1.3.6.1.3.x) may be used for this purpose. 
Practices for IANA assignment of these Internet Experimental numbers 
are detailed in RFC 2578 [RFC2578]. 


3.2. Protocol Mechanisms 
LDAP provides a number of Root DSA-Specific Entry (DSE) attributes 
for discovery of protocol mechanisms identified by OIDs, including 


the supportedControl, supportedExtension, and supportedFeatures 
attributes [RFC4512]. 
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A registry of OIDs used for discovery of protocol mechanisms is 
provided to allow implementors and others to locate the technical 
specification for these protocol mechanisms. Future specifications 
of additional Root DSE attributes holding values identifying protocol 
mechanisms MAY extend this registry for their values. 


Protocol mechanisms are registered on a First Come First Served 
basis. 


3.3. LDAP Syntaxes 


This registry provides a listing of LDAP syntaxes [RFC4512]. Each 

LDAP syntax is identified by an OID. This registry is provided to 

allow implementors and others to locate the technical specification 
describing a particular LDAP Syntax. 


LDAP Syntaxes are registered on a First Come First Served with 
Specification Required basis. 


Note: Unlike object classes, attribute types, and various other kinds 
of schema elements, descriptors are not used in LDAP to 
identify LDAP Syntaxes. 


3.4. Object Identifier Descriptors 


LDAP allows short descriptive names (or descriptors) to be used 
instead of a numeric Object Identifier to identify select protocol 
extensions [RFC4511], schema elements [RFC4512], LDAP URL [RFC4516] 
extensions, and other objects. 


Although the protocol allows the same descriptor to refer to 
different object identifiers in certain cases and the registry 
supports multiple registrations of the same descriptor (each 
indicating a different kind of schema element and different object 
identifier), multiple registrations of the same descriptor are to be 
avoided. All such multiple registration requests require Expert 
Review. 


Descriptors are restricted to strings of UTF-8 [RFC3629] encoded 
Unicode characters restricted by the following ABNF: 


name = keystring 
Descriptors are case insensitive. 
Multiple names may be assigned to a given OID. For purposes of 


registration, an OID is to be represented in numeric OID form (e.g., 
1.1.0.23.40) conforming to the following ABNF: 
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numericoid = number 1*( DOT number ) 


While the protocol places no maximum length restriction upon 
descriptors, they should be short. Descriptors longer than 48 
characters may be viewed as too long to register. 


A value ending with a hyphen ("-") reserves all descriptors that 
start with that value. For example, the registration of the option 
"descrFamily-—" reserves all options that start with "descrFamily-" 
for some related purpose. 


Descriptors beginning with "x-" are for Private Use and cannot be 
registered. 


Descriptors beginning with "e-" are reserved for experiments and will 
be registered on a First Come First Served basis. 


All other descriptors require Expert Review to be registered. 
The registrant need not "own" the OID being named. 


The OID name space is managed by the ISO/IEC Joint Technical 
Committee 1 - Subcommittee 6. 


3.5. AttributeDescription Options 


An AttributeDescription [RFC4512] can contain zero or more options 
specifying additional semantics. An option SHALL be restricted to a 
string of UTF-8 encoded Unicode characters limited by the following 
ABNF: 


option = keystring 
Options are case insensitive. 
While the protocol places no maximum length restriction upon option 
strings, they should be short. Options longer than 24 characters may 
be viewed as too long to register. 
Values ending with a hyphen ("-") reserve all option names that start 
with the name. For example, the registration of the option 
"optionFamily-—" reserves all options that start with "optionFamily-" 


for some related purpose. 


Options beginning with "x-" are for Private Use and cannot be 
registered. 
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Options beginning with "e-" are reserved for experiments and will be 
registered on a First Come First Served basis. 


All other options require Standards Action or Expert Review with 
Specification Required to be registered. 


3.6. LDAP Message Types 


Each protocol message is encapsulated in an LDAPMessage envelope 
[RFC4511. The protocolOp CHOICE indicates the type of message 
encapsulated. Each message type consists of an ASN.1 identifier in 
the form of a keyword and a non-negative choice number. The choice 
number is combined with the class (APPLICATION) and data type 
(CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message’s 
encoding. The choice numbers for existing protocol messages are 
implicit in the protocol’s ASN.1 defined in [RFC4511]. 


New values will be registered upon Standards Action. 


Note: LDAP provides extensible messages that reduce but do not 
eliminate the need to add new message types. 


3.7. LDAP Authentication Method 
The LDAP Bind operation supports multiple authentication methods 
[RFC4511]. Each authentication choice consists of an ASN.1 


identifier in the form of a keyword and a non-negative integer. 


The registrant SHALL classify the authentication method usage using 
one of the following terms: 


COMMON - method is appropriate for common use on the 
Internet. 

LIMITED USE - method is appropriate for limited use. 

OBSOLETE - method has been deprecated or otherwise found to 


be inappropriate for any use. 


Methods without publicly available specifications SHALL NOT be 
classified as COMMON. New registrations of the class OBSOLETE cannot 
be registered. 


New authentication method integers in the range 0-1023 require 
Standards Action to be registered. New authentication method 
integers in the range 1024-4095 require Expert Review with 
Specification Required. New authentication method integers in the 
range 4096-16383 will be registered on a First Come First Served 
basis. Keywords associated with integers in the range 0-4095 SHALL 
NOT start with "e-" or "x-". Keywords associated with integers in 
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the range 4096-16383 SHALL start with "e-". Values greater than or 
equal to 16384 and keywords starting with "x-" are for Private Use 
and cannot be registered. 


Note: LDAP supports Simple Authentication and Security Layers 
[RFC4422] as an authentication choice. SASL is an extensible 
authentication framework. 


3.8. LDAP Result Codes 


LDAP result messages carry a resultCode enumerated value to indicate 


the outcome of the operation [RFC4511]. Each result code consists of 
an ASN.1 identifier in the form of a keyword and a non-negative 
integer. 


New resultCodes integers in the range 0-1023 require Standards Action 
to be registered. New resultCode integers in the range 1024-4095 
require Expert Review with Specification Required. New resultCode 
integers in the range 4096-16383 will be registered on a First Come 
First Served basis. Keywords associated with integers in the range 
0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with 
integers in the range 4096-16383 SHALL start with "e-". Values 
greater than or equal to 16384 and keywords starting with "x-" are 
for Private Use and cannot be registered. 


3.9. LDAP Search Scope 


LDAP SearchRequest messages carry a scope-enumerated value to 
indicate the extent of search within the DIT [RFC4511]. Each search 
value consists of an ASN.1 identifier in the form of a keyword and a 
non-negative integer. 


New scope integers in the range 0-1023 require Standards Action to be 
registered. New scope integers in the range 1024-4095 require Expert 
Review with Specification Required. New scope integers in the range 
4096-16383 will be registered on a First Come First Served basis. 
Keywords associated with integers in the range 0-4095 SHALL NOT start 
with "e-" or "x-". Keywords associated with integers in the range 
4096-16383 SHALL start with "e-". Values greater than or equal to 
16384 and keywords starting with "x-" are for Private Use and cannot 
be registered. 


3.10. LDAP Filter Choice 
LDAP filters are used in making assertions against an object 
represented in the directory [RFC4511]. The Filter CHOICE indicates 


a type of assertion. Each Filter CHOICE consists of an ASN.1 
identifier in the form of a keyword and a non-negative choice number. 
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The choice number is combined with the class (APPLICATION) and data 
type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the 
message’s encoding. 


Note: LDAP provides the extensibleMatching choice, which reduces but 
does not eliminate the need to add new filter choices. 


3.11. LDAP ModifyRequest Operation Type 


The LDAP ModifyRequest carries a sequence of modification operations 
[RFC4511]. Each kind (e.g., add, delete, replace) of operation 
consists of an ASN.1 identifier in the form of a keyword and a non- 
negative integer. 


New operation type integers in the range 0-1023 require Standards 
Action to be registered. New operation type integers in the range 
1024-4095 require Expert Review with Specification Required. New 
operation type integers in the range 4096-16383 will be registered on 
a First Come First Served basis. Keywords associated with integers 
in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords 
associated with integers in the range 4096-16383 SHALL start with 
"e-", Values greater than or equal to 16384 and keywords starting 
with "x-" are for Private Use and cannot be registered. 


3.12. LDAP authzId Prefixes 


Authorization Identities in LDAP are strings conforming to the 
<authzId> production [RFC4513]. This production is extensible. Each 
new specific authorization form is identified by a prefix string 
conforming to the following ABNF: 


prefix = keystring COLON 
COLON = %x3A ; COLON (":" U+003A) 


Prefixes are case insensitive. 
While the protocol places no maximum length restriction upon prefix 


strings, they should be short. Prefixes longer than 12 characters 
may be viewed as too long to register. 


Prefixes beginning with "x-" are for Private Use and cannot be 
registered. 
Prefixes beginning with "e-" are reserved for experiments and will be 


registered on a First Come First Served basis. 


All other prefixes require Standards Action or Expert Review with 
Specification Required to be registered. 
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3.13. Directory Systems Names 


The IANA-maintained "Directory Systems Names" registry [IANADSN] of 
valid keywords for well-known attributes was used in the LDAPv2 
string representation of a distinguished name [RFC1779]. LDAPv2 is 
now Historic [RFC3494]. 


Directory systems names are not known to be used in any other 
context. LDAPv3 [RFC4514] uses Object Identifier Descriptors 
[Section 3.2] (which have a different syntax than directory system 
names). 


New Directory System Names will no longer be accepted. For 
historical purposes, the current list of registered names should 
remain publicly available. 


4. Registration Procedure 


The procedure given here MUST be used by anyone who wishes to use a 
new value of a type described in Section 3 of this document. 


The first step is for the requester to fill out the appropriate form. 
Templates are provided in Appendix A. 


If the policy is Standards Action, the completed form SHOULD be 
provided to the IESG with the request for Standards Action. Upon 
approval of the Standards Action, the IESG SHALL forward the request 
(possibly revised) to IANA. The IESG SHALL be regarded as the 
registration owner of all values requiring Standards Action. 


If the policy is Expert Review, the requester SHALL post the 
completed form to the <directory@apps.ietf.org> mailing list for 
public review. The review period is two (2) weeks. If a revised 
form is later submitted, the review period is restarted. Anyone may 
subscribe to this list by sending a request to <directory- 
request@apps.ietf.org>. During the review, objections may be raised 
by anyone (including the Expert) on the list. After completion of 
the review, the Expert, based on public comments, SHALL either 
approve the request and forward it to the IANA OR deny the request. 
In either case, the Expert SHALL promptly notify the requester of the 
action. Actions of the Expert may be appealed [RFC2026]. The Expert 
is appointed by Applications Area Directors. The requester is viewed 
as the registration owner of values registered under Expert Review. 


If the policy is First Come First Served, the requester SHALL submit 
the completed form directly to the IANA: <iana@iana.org>. The 
requester is viewed as the registration owner of values registered 
under First Come First Served. 
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Neither the Expert nor IANA will take position on the claims of 
copyright or trademark issues regarding completed forms. 


Prior to submission of the Internet Draft (I-D) to the RFC Editor but 
after IESG review and tentative approval, the document editor SHOULD 
revise the I-D to use registered values. 


5. Registration Maintenance 
This section discusses maintenance of registrations. 
5.1. Lists of Registered Values 


IANA makes lists of registered values readily available to the 
Internet community on its web site: <http://www.iana.org/>. 


5.2. Change Control 


The registration owner MAY update the registration subject to the 
same constraints and review as with new registrations. In cases 
where the registration owner is unable or is unwilling to make 
necessary updates, the IESG MAY assume ownership of the registration 
in order to update the registration. 


5.3. Comments 


For cases where others (anyone other than the registration owner) 
have significant objections to the claims in a registration and the 
registration owner does not agree to change the registration, 
comments MAY be attached to a registration upon Expert Review. For 
registrations owned by the IESG, the objections SHOULD be addressed 
by initiating a request for Expert Review. 


The form of these requests is ad hoc, but MUST include the specific 
objections to be reviewed and SHOULD contain (directly or by 
reference) materials supporting the objections. 


6. Security Considerations 


The security considerations detailed in BCP 26 [RFC2434] are 
generally applicable to this document. Additional security 
considerations specific to each name space are discussed in Section 
3, where appropriate. 


Security considerations for LDAP are discussed in documents 
comprising the technical specification [RFC4510]. 


Zeilenga Best Current Practice [Page 10] 


RFC 4520 IANA Considerations for LDAP June 2006 


7. Acknowledgement 


This document is a product of the IETF LDAP Revision (LDAPBIS) 
Working Group (WG). This document is a revision of RFC 3383, also a 
product of the LDAPBIS WG. 


This document includes text borrowed from "Guidelines for Writing an 
IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and 
Harald Alvestrand. 


8. References 
8.1. Normative References 
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 


3", BCP 9, RFC 2026, October 1996. 


[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997. 


[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 
IANA Considerations Section in RFCs", BCP 26, RFC 2434, 
October 1998. 


[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 
"Structure of Management Information Version 2 (SMIv2)", 
STD 58, RFC 2578, April 1999. 


[RFC3629] Yergeau, F., "“UTF-8, a transformation format of ISO 
10646", STD 63, RFC 3629, November 2003. 


[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 
Specifications: ABNF", RFC 4234, October 2005. 


[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 
(LDAP): Technical Specification Road Map", RFC 4510, June 
2006. 


[RFC4511] Sermersheim, J., Ed., “Lightweight Directory Access 
Protocol (LDAP): The Protocol", RFC 4511, June 2006. 


[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 
(LDAP): Directory Information Models", RFC 4512, June 
2006. 


[RFC4513] Harrison, R., Ed., “Lightweight Directory Access Protocol 


(LDAP): Authentication Methods and Security Mechanisms", 
RFC 4513, June 2006. 


Zeilenga Best Current Practice [Page 11] 


RFC 4520 


[RFC4516] 


[Unicode] 


[X.680] 


IANA Considerations for LDAP June 2006 


Smith, M., Ed. and T. Howes, "Lightweight Directory Access 
Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 
2006. 


The Unicode Consortium, "The Unicode Standard, Version 
3.2.0" is defined by "The Unicode Standard, Version 3.0" 
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 
as amended by the "Unicode Standard Annex #27: Unicode 
3.1" (http://www.unicode.org/reports/tr27/) and by the 
"Unicode Standard Annex #28: Unicode 3.2" 
(http://www.unicode.org/reports/tr28/). 


International Telecommunication Union - Telecommunication 
Standardization Sector, "Abstract Syntax Notation One 
(ASN.1) - Specification of Basic Notation", X.680(2002) 
(also ISO/IEC 8824-1:2002). 


8.2. Informative References 


[RFC1779] 


[RFC3494] 


[RFC4514] 


[RFC4422] 


[IANADSN] 


Zeilenga 


Kille, S., "A String Representation of Distinguished 
Names", RFC 1779, March 1995. 


Zeilenga, K.,"Lightweight Directory Access Protocol 
version 2 (LDAPv2) to Historic Status", RFC 3494, March 
2003. 


Zeilenga, K., Ed., “Lightweight Directory Access Protocol 
(LDAP): String Representation of Distinguished Names", RFC 
4514, June 2006. 


Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 
Authentication and Security Layer (SASL)", RFC 4422, June 
2006. 


IANA, "Directory Systems Names", 
http://www.iana.org/assignments/directory-system-names. 


Best Current Practice [Page 12] 


RFC 4520 IANA Considerations for LDAP June 2006 


Appendix A. Registration Templates 
This appendix provides registration templates for registering new 
LDAP values. Note that more than one value may be requested by 
extending the template by listing multiple values, or through use of 
tables. 
A.1. LDAP Object Identifier Registration Template 
Subject: Request for LDAP OID Registration 
Person & email address to contact for further information: 
Specification: (I-D) 
Author/Change Controller: 
Comments: 
(Any comments that the requester deems relevant to the request.) 
A.2. LDAP Protocol Mechanism Registration Template 


Subject: Request for LDAP Protocol Mechanism Registration 


Object Identifier: 


Description: 

Person & email address to contact for further information: 
Usage: (One of Control or Extension or Feature or other) 
Specification: (RFC, I-D, URI) 

Author/Change Controller: 

Comments: 


(Any comments that the requester deems relevant to the request.) 
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A.3. LDAP Syntax Registration Template 

Subject: Request for LDAP Syntax Registration 

Object Identifier: 

Description: 

Person & email address to contact for further information: 

Specification: (RFC, I-D, URI) 

Author/Change Controller: 

Comments: 

(Any comments that the requester deems relevant to the request.) 
A.4. LDAP Descriptor Registration Template 

Subject: Request for LDAP Descriptor Registration 

Descriptor (short name): 

Object Identifier: 

Person & email address to contact for further information: 


Usage: (One of administrative role, attribute type, matching rule, 
name form, object class, URL extension, or other) 


Specification: (RFC, I-D, URI) 
Author/Change Controller: 


Comments: 


(Any comments that the requester deems relevant to the request.) 
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A.5. LDAP Attribute Description Option Registration Template 


Subject: Request for LDAP Attribute Description Option Registration 
Option Name: 


Family of Options: (YES or NO) 

Person & email address to contact for further information: 
Specification: (RFC, I-D, URI) 

Author/Change Controller: 

Comments: 


(Any comments that the requester deems relevant to the request.) 


A.6. LDAP Message Type Registration Template 
Subject: Request for LDAP Message Type Registration 
LDAP Message Name: 
Person & email address to contact for further information: 
Specification: (Approved I-D) 
Comments: 
(Any comments that the requester deems relevant to the request.) 
A.7. LDAP Authentication Method Registration Template 
Subject: Request for LDAP Authentication Method Registration 
Authentication Method Name: 
Person & email address to contact for further information: 


Specification: (RFC, I-D, URI) 


Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE) 
Author/Change Controller: 
Comments: 


(Any comments that the requester deems relevant to the request.) 


Zeilenga Best Current Practice [Page 15] 


RFC 4520 IANA Considerations for LDAP June 2006 


A.8. LDAP Result Code Registration Template 
Subject: Request for LDAP Result Code Registration 
Result Code Name: 
Person & email address to contact for further information: 
Specification: (RFC, I-D, URI) 
Author/Change Controller: 
Comments: 
(Any comments that the requester deems relevant to the request.) 
A.8. LDAP Search Scope Registration Template 
Subject: Request for LDAP Search Scope Registration 
Search Scope Name: 
Filter Scope String: 
Person & email address to contact for further information: 
Specification: (RFC, I-D, URI) 
Author/Change Controller: 
Comments: 


(Any comments that the requester deems relevant to the request.) 
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A.9. LDAP Filter Choice Registration Template 

Subject: Request for LDAP Filter Choice Registration 

Filter Choice Name: 

Person & email address to contact for further information: 

Specification: (RFC, I-D, URI) 

Author/Change Controller: 

Comments: 

(Any comments that the requester deems relevant to the request.) 
A.10. LDAP ModifyRequest Operation Registration Template 

Subject: Request for LDAP ModifyRequest Operation Registration 

ModifyRequest Operation Name: 

Person & email address to contact for further information: 

Specification: (RFC, I-D, URI) 

Author/Change Controller: 

Comments: 

(Any comments that the requester deems relevant to the request.) 
Appendix B. Changes since RFC 3383 


This informative appendix provides a summary of changes made since 
RFC 3383. 


- Object Identifier Descriptors practices were updated to require 
all descriptors defined in RFCs to be registered and 
recommending all other descriptors (excepting those in 
private-use name space) be registered. Additionally, all 
requests for multiple registrations of the same descriptor are 
now subject to Expert Review. 


- Protocol Mechanisms practices were updated to include values of 
the ’supportedFeatures’ attribute type. 
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Author’s 
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LDAP Syntax, Search Scope, Filter Choice, ModifyRequest 
operation, and authzId prefixes registries were added. 


References to RFCs comprising the LDAP technical specifications 
have been updated to latest revisions. 


References to ISO 10646 have been replaced with [Unicode]. 


The "Assigned Values" appendix providing initial registry 
values was removed. 


Numerous editorial changes were made. 


Address 


Kurt D. Zeilenga 
OpenLDAP Foundation 


EMail: 


Zeilenga 


Kurt @OpenLDAP.org 


Best Current Practice [Page 18] 


RFC 4520 IANA Considerations for LDAP June 2006 


Full Copyright Statement 
Copyright (C) The Internet Society (2006). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
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